Detailed information about the network resources for all domains of all operators involved in a network is required for service setup. An operator must disclose sufficient information about the operator's network to enable other operators to use it. However, the operator typically desires to keep the real network topology hidden in order to prevent the revelation of business-critical information to competitors.
The hierarchical routing proposed by the Optical Interworking Forum (OIF) is a strong candidate technology to perform multi-domain Traffic Engineering (TE). In OIF External Network-Network Interface (E-NNI) Routing, a Routing Controller (RC) in each domain is responsible for the dissemination of intra-domain routing information.
To support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the International Telecommunication Union (ITU-T) and in particular of the hierarchical routing, D. Papadimitriou, RFC5787 “OSPFv2 Routing Protocols Extensions for ASON Routing”, March, 2010 defines the required routing extensions of the Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols. The routing extensions include reachability, sub-TLVs, discovery procedures and extensions, and import/export rules.
In “The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS”, by D. King and A. Farrel, July 2009 (King), King proposes a Parent Path Computation Element (PCE) mechanism which can exploit the ASON routing architecture to provide paths across subnetworks and to determine end-to-end paths in networks constructed from multiple subnetworks or routing areas. The Parent PCE maintains a Traffic Engineering Database (TED) for its domain. The mechanism for building the parent TED will probably rely heavily on administrative configuration and commercial issues. In models such as ASON, it is possible to consider a separate instance of an Interior Gateway Protocol (IGP) running within the parent domain where the participating protocol speakers are the nodes directly present in that domain and the PCEs (RCs) responsible for each of the Child domains.
However, no details are reported on the way the RCs determine the abstracted intra-domain routing information to disseminate to other domains and the implications that such dissemination imposes during successive path computation requests.
In the OIF abstract link model dissemination discussed in King, an RC advertises the full mesh of virtual links between all Border Node (BN) pairs. Each virtual intra-domain link is described through Open Shortest Path First Traffic Engineering (OSPF-TE) Link State Advertisement (TE-LSA).
FIG. 1 is a simplified block diagram of a system 100 employing an existing multi-domain TE architecture. The network includes an RC 102 and two PCEs per domain. The RC 102 is responsible for intra-domain link advertisement. An I-PCE 104 (or Child PCE) is responsible for intra-domain computations and an E-PCE 106 (or Parent PCE) is responsible for inter-domain (hierarchical) path computations. The I-PCE 104 includes an I-TE Database (I-TED) 108. The E-PCE 106 includes an E-TED 110. The I-PCE 104 and the E-PCE 106 both retrieve TE information through the I-TED and the E-TED listening or through other mechanisms (e.g., from the Network Management System (NMS)).
The RC 102, the I-PCE 104, and the E-PCE 106 cooperate with each other to perform virtual intra-domain link advertisement (asynchronous to the requests) and multi-domain path computations (upon request). To perform virtual intra-domain link advertisement, the RC acts as a Path Computation Client (PCC) and is able to request the I-PCE to perform the path computations having the BN pairs as end-points and the minimum delay as an objective function. By exploiting the current PCE Communication Protocol (PCEP) protocol specifications (RFC5440), the I-PCE returns the computed least cost path for each BN pair.
In addition, the I-PCE returns, for each path, the associated TE metric value, which corresponds to the BN-BN delay, such as mi,j from BNi to BNj. The mi,j value is then inserted as a TE metric value in the TE LSAs of the BNi-BNj intra-domain link advertised by RC to other RCs belonging to different domains. According to such information, a PCC belonging to a different domain may request the provisioning of a multi-domain connection traversing the considered domain. In this case, the E-PCE maps the received multi-domain request to an intra-domain request between the identified BNs. The E-PCE then sends a Path Computation Request (PCReq) message to the I-PCE including the required TE attributes (e.g., bandwidth) and the related TE metric (advertised by the RC). This TE metric value is then included as a TE Metric Bound with a B flag activated in the PCEP PCReq Metric Object. Thus, the I-PCE computes a path (e.g., in Wavelength Switched Optical Network (WSON) by retrieving it from a set of pre-computed paths) subject to the advertised delay constraint.
However, this existing architecture of the network 100, which exploits the current PCEP specifications (e.g., PCReq Metric Object, B flag, etc), only allows the RC to retrieve the minimum TE metric value. Thus, the path used for any subsequent connection provisioning is only associated with the advertised minimum value. Because of this limited selection criteria, the overall intra-domain network resource utilization may be significantly degraded.